Method and apparatus for load sharing and data distribution in servers

ABSTRACT

A method and apparatus for distributing load between a plurality of servers, for handling incoming service requests in a server system. When a service request in received in an access node, a primary server is assigned out of a set of primary servers, using a first scheduling algorithm, for performing a processing task for the received service reqest. The first scheduling algorithm is capable of selecting any primary server. Further, a secondary server is assigned out of a set of secondary servers, using a second scheduling algorithm, for perfomring a storing task for the received service request. The second scheduling algorithm is capable of selecting one specific secondary servers for a storing task.

TECHNICAL FIELD

The present invention relates generally to a method and apparatus fordistributing data and processing load between plural servers of acommunication service provider. In particular, the invention isconcerned with scheduling processing and storing load to achieve anefficient utilisation of computer and data storage resources.

BACKGROUND OF THE INVENTION AND PRIOR ART

A multitude of different fixed and mobiletelecommunication/datacommunication services have been developed, inaddition to the traditional voice calling and short text messaging. Forexample, Internet browsing has rapidly become very popular, and inrecent years the wireless domain has converged with the Internet. Mobileterminals are now available having functionality for connecting to theInternet over a wireless access network to obtain information andservices from sites and servers located anywhere throughout the world.Moreover, new technologies for mobile communication are introduced,providing greater network capacity and higher transmission bitrates. Inparticular, GPRS (General Packet Radio Service) and WCDMA (Wideband CodeDivision Multiple Access) networks are currently emerging for enablingwireless data services that require a wide range of different datarates. The data communicated in many new services may include voice,text, images, audio files and video files in various different formatsand combinations.

By way of example, mobile instant messaging and presence services arerapidly becoming popular. Instant messaging is known from the world offixed PCs (Personal Computers), including message status reporting andvarious group and contact list features. Presence services involveinformation on the location of mobile terminals and enable users toreceive messages according to their profile and availability. A userprofile can be personal and may be defined by preferences, interests andhobbies, as well as more temporary factors, such-as user availabilityand current moods. Messages and content services can also be delivereddepending on the present location, availability and terminalcapabilities. It can be readily understood that such services requirethe storage of considerable amounts of retrievable user-specific data,which in many cases need to be frequently updated due to their dynamicnature.

The demands for telecommunication services are thus increasing rapidly,and service providers are established all over the world, equipped withhardware and software resources to meet these demands. In particular,means for processing service requests and data, as well as means forstoring huge amounts of data are needed. Consequently, a serviceprovider must be able to efficiently control the processing and storingmeans which are typically comprised in a system of different servicecomponents such as servers. The expression “server” will be usedhereafter to represent any hardware and/or software for storing and/orprocessing data. A server may be configured to provide one or morespecific services.

As seen from the examples given above, different types of stored datamay be of a very dynamic nature, needing frequent updatings. Moreover,server systems must be reconfigured from time to time as the needschange for processing and storing, e.g., due to changing demands ofservice requests, added or removed subscribers and the introduction,modification or deletion of services. The workload on servers oftenincreases rapidly so that individual servers are easily overloaded, atleast for a short time, in particular popular web servers. To overcomeoverloading problems in servers, basically two solutions are available.

Firstly, an existing server may be upgraded to increase its computingand/or storing capabilities. However, the server will soon be overloadedagain if the amount of service requests and/or needs for storagecontinue to increase, requiring further upgrading, which can be complexand costly to perform.

Secondly, it is possible to add further servers to meet a higher load.The concept of virtual servers has been proposed to provide load sharingbetween plural servers. A virtual server is a scalable server built on acluster of real servers, which is transparent to end users such that theusers see only a single virtual server. The front-end of the realservers is a node, sometimes called “load balancer”, configured toschedule service requests to the different real servers. Scalability isachieved by transparently adding or removing a server in the cluster.

For an Internet service provider or the like controlling a plurality ofservers, processing and storing load must be shared between the servers.This is necessary in order to efficiently utilise available computingand storing resources, and to handle hotspots and avoid bottlenecks. Asmentioned above, large amounts of data must be stored and should also beeasy to find and retrieve. Furthermore, it must be possible toefficiently execute resource demanding processing tasks, requiring oneor more computers. In order to handle large amounts of the same orsimilar computing requests, it is quite common that these requests mustbe shared between plural computers.

It is thus a problem to efficiently distribute processing and storingload between a plurality of servers, yet enabling easy retrieval ofstored data. In current solutions involving the distribution of data tobe stored or the processing of data, a server is often allocated to aclient upon a login request. The allocation scheme used for selecting aserver is normally based on the current load on a predetermined set ofservers, such that the server having the lowest current load, withrespect to memory resources and/or CPU (Central Processing Unit)capability, etc, is selected for the client. Server allocation istypically performed by using a load manager node or the like.

The most simple current solution for load sharing is a “Round Robin”allocation scheme. Further load sharing solutions are known which aremore complex, such as “Weighted Round Robin”, “Least Connection”,“Weighted Least Connection”, “Locality Based Least Connection”,“Destination Hashing” and “Source Hashing”.

However, the solutions mentioned above are relatively complex to use,resulting in problems related to supervision, operation and maintenance,since it is difficult to predict where data will be distributed andstored, as well as where specific computing-intensive tasks willactually be performed. Another problem is that it is sometimes notpossible to perform linear scaling of a server system, e.g., expandingresources by adding servers to the system.

Furthermore, it may be difficult to find and retrieve data being storedin one or more servers if no reference or pointer to the data isproperly stored somewhere. The client performing the login may have aproper reference to the data, but no other client or device can find andretrieve the data without the reference, unless so-called “brute forcesearches” are used among a set of servers.

“Round Robin” scheduling is only suitable for distributing processingload, since processing tasks are not affected by in which server theyare performed. On the other hand, in data storage distribution, it mustbe possible to find and retrieve data stored in one of several servers,which cannot be done by using Round Robin but requires the use ofpointers or references as described above. Furthermore, a common basicproblem with some of the other scheduling methods mentioned above, isthat they use IP (Internet Protocol) addressing for scheduling. Since aplurality of clients can reside behind a single IP address (proxy, NAT,etc.), these can neither be used for data distribution nor load sharing.

SUMMARY OF THE INVENTION

The object of the present invention is to reduce or eliminate theproblems outlined above and provide efficient distribution of processingand storing load for incoming service requests. This object and othersare obtained by providing a method and apparatus for schedulingprocessing and storing load in a system of plural servers.

A service request is received in a server system comprising a pluralityof servers. A primary server is assigned out of a set of primaryservers, using a first scheduling algorithm, for performing a processingtask for the received service request. The first scheduling algorithm iscapable of selecting any primary server in the set of primary servers.Further, a secondary server is assigned out of a set of secondaryservers, using a second scheduling algorithm, for performing a storingtask for the received service request. The second scheduling algorithmis capable of selecting a specific secondary server in the set ofsecondary servers.

The first scheduling algorithm is preferably a Round Robin algorithm,and the second scheduling algorithm is preferably a hashing algorithm.Using the second scheduling algorithm may include deriving a hash numberfrom a user ID and calculating a server ID number from the derived hashnumber. The following algorithm may then be used:server ID=hash(user ID)modulo n  (1)where n is the number of possible secondary servers, and the modulooperator providing an integer between 0 and n−1.

If a further processing task must be performed for the received servicerequest, a primary server is assigned out of the set of primary servers,using a third scheduling algorithm being capable of selecting anyprimary server. The third scheduling algorithm may be the same as thefirst scheduling algorithm.

When using the invention, primary servers can be assigned on an IPlevel, where the primary servers are designated and configured forhandling requests in different protocols. Furthermore, the secondaryservers can be assigned on an application level, where the secondaryservers are designated and configured for handling storing tasks indifferent service applications.

The processing task may involve any of: analysing the received servicerequest, processing of data and running certain applications fordelivering the requested service. The storing task may involve any of:storing new data, updating already stored data, and retrieving storeddata.

The invention further embraces a server system comprising a plurality ofservers for handling incoming telecommunication service requests. Theserver system includes an access node, a set of primary servers capableof performing at least one common processing task, and a set ofsecondary servers capable of performing at least one common storingtask. The access node is connected to each primary server and eachprimary server is connected to each secondary server. The access node isconfigured to use the first scheduling algorithm to assign any primaryserver for performing a processing task for a received service request.Each primary server is configured to use the second scheduling algorithmto assign a specific secondary server for performing a storing task fora received service request, the specific secondary server correspondingto a client or session involved in that storing task.

Each secondary server may further be configured to use the thirdscheduling algorithm to assign any primary server for performing afurther processing task.

The primary servers may be divided into different groups for requests indifferent protocols, where a first group is configured to handle HTTP(Hyper Text Transfer Protocol) requests, and a second group isconfigured to handle HTTPS (HTTP Secure) requests. The first schedulingalgorithm is then used for a request within one of the primary servergroups, depending on the service request protocol.

The access node may further comprise a primary access node beingconfigured as a normally working node handling incoming requests, and asecondary access node being configured to monitor the activities of theprimary node. The secondary access node is configured to take over thehandling of requests if the primary node for some reason fails and isshut down.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail and withreference to the accompanying drawings, in which:

FIG. 1 is a schematic overview of a communication scenario in which thepresent invention can be used.

FIG. 2 is a block diagram of an exemplary server system according to oneembodiment.

FIG. 3 is a more detailed block diagram of components in a server systeminvolved with an incoming service request.

FIG. 4 is a flow chart illustrating a procedure for handling a servicerequest.

DESCRIPTION OF PREFERRED EMBODIMENTS

In FIG. 1, a schematic communication scenario is illustrated in whichthe present invention can be used. A plurality of client terminals 100are connected to a backbone network 102, such as the Internet. Theclient terminals 100 may be fixed or mobile, such as wired terminals, orwireless terminals connected to a mobile access network 104 over an airinterface, as indicated in the figure. A plurality of service providers106 are likewise connected to the backbone network 102, each comprisingone or more servers for executing telecommunication services requestedfor the client terminals 100. In reality, various further networksand/or nodes are typically involved in communication routes betweenclients and service providers, although not shown here for the sake ofsimplicity.

A client terminal 100 may thus initiate a specific telecommunicationservice by sending a service request over the backbone network 102 to aservice provider 106. The contacted service provider then activates oneor more suitable service applications in response thereto. Activating aservice application may involve various processing and storing tasks,which will be discussed in more detail below.

Service applications may also be triggered without a preceding terminalrequest, such as through a “push” mechanism as used for example in thecontext of WAP (Wireless Application Protocol). A service request maythus originate from another service provider or network operator,needing data of a certain client or ongoing session. For example, aservice provider may want to transmit certain information to mobilestations as they enter a specific area. In that case, the serviceprovider will request for needed user data, such as terminalcapabilities and client profile, e.g., including predefined preferencesand interests.

As mentioned in the background section, service providers are typicallyequipped with a plurality of servers in order to meet the demands forservices from clients and other service providers. Thus, the samefunctionality is duplicated in several servers, thereby being capable ofperforming the same service tasks simultaneously for plural clients, beit data processing or storing tasks. The present invention is concernedwith a method and apparatus for efficiently utilising available serversby distributing the load over the servers.

The invention utilises the fact that service tasks executed by serverscan be divided into processing tasks and storing tasks. “Processingtasks” may involve analysing service requests, processing of data andrunning certain applications for delivering requested services. “Storingtasks” may involve storing new client-specific, session-specific orconfiguring data, updating already stored data, and retrieving storeddata. For example, a service request may require the retrieval ofcertain data which is used as input for executing a specific processingtask or service application.

In FIG. 2, an exemplary server system 200 is illustrated for providingone or more services for client terminals, in accordance with theinvention. The server system 200 comprises an access node 202 acting asthe first access point for incoming requests and data. More than oneaccess node may be used within the scope of the invention. For example,a primary access node 202 may be configured as a normally working nodehandling incoming requests, where a secondary access node 202 a monitorsthe activities of the primary node. Thereby, the secondary node 202 a isconfigured to take over the handling of requests, if the primary node202 for some reason fails and is shut down.

The access node 202 is connected to a set of primary servers 204, whichare configured to primarily perform processing tasks. Each primaryserver 204 is in turn connected to a set of secondary servers 206, whichare configured to primarily perform storing tasks. Thus, each secondaryserver 206 can be reached from all primary servers 204. The primaryservers 204 are all capable of performing at least one common processingtask, and the secondary servers 206 are all capable of performing atleast one common storing task. The primary and secondary servers may inaddition be capable of performing other tasks as well, which is howevernot within the scope of the present invention.

In order to distribute processing tasks over the primary servers 204, afirst scheduling algorithm is used in the access node 202 for assigninga primary server 204 for performing any processing task for an incomingservice request. Similarly, a second scheduling algorithm is used ineach primary server 204 for distributing incoming storing tasks over thesecondary servers 206.

An incoming service request for a specific client or ongoing session isthus first received in the access node 202. Then, a primary server 204is assigned by the access node 202 to process the request, by using thefirst scheduling algorithm. IT the service request further involves astoring task, the assigned primary server 204 applies the secondscheduling algorithm for finding a secondary server 206 to perform thestoring task.

The first and second scheduling algorithms are selected according to thenature of the processing and storing tasks, which are different fromeach other. A processing task can be performed by any of the primaryservers 204, regardless of which client or session the task is directedto. It is even desirable that different primary servers 204 can be usedfor repeated requests for the same client in order to achieve anefficient load distribution, since the behaviour and profiles can differbetween different clients. For example, one client may require moreprocessing capacity than others by, e.g., constantly requesting moreadvanced service functionality or larger amounts of information.

On the other hand, storing tasks should be performed by the samesecondary server 206 for each specific client, since client-specificdata is preferably stored in only one secondary server assigned to thatclient. Otherwise, the same client-specific data must be stored in allsecondary servers 206. If the storing task is storing new data for a newclient, any secondary server 206 can be initially assigned for the task.However, if the storing task involves retrieving already stored data fora client, the second scheduling algorithm must always give the sameresult, i.e. point to the secondary server assigned to that client inwhich that client data is stored. Thereby, the need for using separatepointers or references to specific secondary servers is eliminated.

The same applies also for processing and storing tasks involvingsession-specific data. Client data and session data is hereaftercollectively referred to as “user data”.

In one embodiment, the primary servers may be configured to handlerequests using different protocols and may be divided into differentgroups accordingly. For example, a first primary server group can beconfigured to handle HTTP (Hyper Text Transfer Protocol) requests, and asecond primary server group can be configured to handle HTTPS (HTTPSecure) requests. The first scheduling algorithm is then used for onlyone of the primary server groups, depending on the protocol of theservice request. In another embodiment, the secondary servers may bedesignated for specific storing tasks in different service applications.For example, the secondary servers may comprise Session servers, InstantMessaging servers, Presence servers, etc. Assigning a primary server 204may thus be done on an “IP level”, i.e. regardless of which service isrequested, while assigning a secondary server 204 may be done on an“application level” depending on the type of service.

To conclude, the first scheduling algorithm is capable of selecting anyprimary server out of a set of primary servers, for a processing task,while the second scheduling algorithm is capable of selecting onespecific server for a storing task corresponding to a client or sessioninvolved in that task. According to a preferred embodiment, a simple“Round Robin” algorithm is used as the first scheduling algorithm, and ahashing algorithm is used as the second scheduling algorithm.

A hashing algorithm means that a hash number is derived from apredetermined identity code of a client or a session, which willhereafter be collectively referred to as a “user ID”. A server identitycan be determined by calculating a corresponding server ID number bymeans of a predetermined algorithm or formula based on the derived hashnumber. For example, the hash number can be a simple checksum or thelike for a binary code of the user ID. According to one embodiment, asecondary server 206 is determined to perform a storing task from thefollowing algorithm:server ID=hash(user ID)modulo n  (1)

-   -   where n is the number of possible secondary servers, as        indicated in FIG. 2. The modulo operator will provide an integer        between 0 and n−1. For example, if four secondary servers        206:0-206:3 are available, i.e. n=4, and one particular client        gives hash(user ID)=14, the server ID=2. Thus, server 206:2 is        selected accordingly. For another client, hash(user ID)=16,        leading to server ID=0, and so forth. Any suitable hashing        function may be used on a user ID, provided that the same server        ID is always derived from the same user ID.

FIG. 3 illustrates, in more detail, components in a server systeminvolved with an incoming service request S, partly using the samereference numbers from FIG. 2. The service request may have been sentfrom a client terminal 100 over the backbone network 102 to a serviceprovider 106, as illustrated in FIG. 1, or may have originated fromanother service provider requesting certain user data or the like. Inthis example, the service request S is “forwarded” between differentunits, which in practice may be done by forwarding the entire request oronly a part thereof or any relevant request for operations needed tohandle the service request S.

The service request S is first received in a receiving unit 300 of anaccess node 202, and a first scheduling algorithm is applied in ascheduling unit 302 for assigning a primary server to process therequest. The first scheduling algorithm is capable of selecting anyprimary server out of a predetermined set of primary servers. In thiscase, primary server 204:C is selected, wherein the service request isforwarded thereto. The primary server 204:C then processes the requestaccordingly in a processing unit 304.

It is then detected that specific data is needed as input to execute therequested service, such as user-specific data, subscription parametersor the like. A second scheduling algorithm is therefore applied in ascheduling unit 306 in the primary server 204:C, for finding andassigning a secondary server to perform a storing task of retrieving theneeded data. The second scheduling algorithm is capable of selecting aspecific secondary server out of a predetermined set of secondaryservers. The second scheduling algorithm may preferably be a hashingalgorithm using a specific client identification or a sessionidentification as input. In this case, secondary server 206:2 isselected, wherein the service request, or at least a request for theneeded data, is forwarded thereto for retrieving the needed data.

Next, it is detected that the requested service requires furtherprocessing work. A third scheduling algorithm is then applied in ascheduling unit 310 in the secondary server 206:2, for assigning aprimary server to process the request further. The third schedulingalgorithm is capable of selecting any primary server out of thepredetermined set of primary servers. It should be noted that it is notrequired that the further processing is performed by the same primaryserver 204:C as previously. In this example, a primary server 204:F isselected by means of the third scheduling algorithm, wherein the servicerequest is forwarded thereto. The third scheduling algorithm may be thesame as the first scheduling algorithm, such as a Round Robin algorithmor the like, being capable of selecting any primary server.

In the following, a practical example in real life will be described,where the present invention is used. When a client sends an instantmessage to another user, the client sends an HTTP POST containing anappropriate xml message, to the server system. This message is firstreceived by a local director, which operates as an access node andhandles IP-level distribution of processing load. The local directorroutes the request to one of several front-end servers, i.e. a primaryserver, using a first scheduling algorithm. Upon receiving the request,the front end server parses the xml and extracts the information neededto execute the request. The front-end server then verifies that theclient has a valid session by sending a request to one of severalsession servers, i.e. a secondary server. Which session server to use isdetermined by applying a hashing algorithm, i.e. a second schedulingalgorithm, to the user ID of the client. When the correct session serveris found, it is checked whether the client has a session stored in theserver. If no corresponding session is found, an error message isreturned. Otherwise, a request is sent to an instant messaging servers.The above-mentioned hashing algorithm may be used again to select thecorrect one.

When the instant messaging server receives the request, an asynchronousevent, containing the instant message, is sent to the front-end server.Upon receiving the event, the front end server checks if the receiver ofthe message has a valid session, i.e. if the receiver is logged in. Ifso, the event is placed in a queue in the session server and a shortmessage is pushed to the client. A WAP push may be used for mobileclients and a UDP packet may be used for PC clients. When the clientreceives this message, the event is fetched from the server through anHTTP POST, thereby removing the event from the queue. If the receivinguser has no valid session, the message contained in the event is storedin the instant messaging server, which then can be retrieved by thereceiver upon log in.

An exemplary Procedure of handling a service request will now be brieflydescribed with reference to the flow chart shown in FIG. 4. The servicerequest is received in a first step 400, wherein a primary server isassigned in a step 402. The request is then processed in the assignedprimary server in a step 404. Thereafter, it is checked, in a step 406,whether the request requires that a storing task is performed. If not,the request handling process ends in a step 408. Otherwise, a secondaryserver is assigned in a step 410 and the storing task Is performedaccordingly in that server, in a step 412. Next, it is checked whetherthe request requires further processing, in a step 414. If not, therequest handling process ends in a step 416. Otherwise, a new primaryserver is assigned in a step 418, and the request is processed furtherin the assigned primary server in a step 420. The new primary server mayor may not be the same as the one assigned in the earlier step 402.

The process may end after step 420, or may continue by returning to step406, as indicated by a dashed arrow in the figure, to check if anyfurther storing task must be performed, and so forth. Hence, dependingon the nature of the requested service, the request may be handled backand forth between the primary and secondary servers.

By using the described invention, the processing and storing load can beefficiently distributed in a system of servers, such that scalabilltyand robustness is achieved.

The present invention enables load sharing on an IP level and datadistribution on an application level, which is possible to scalelinearly. The computing work for selecting which server to be assignedfor handling a particular request can be performed instantly, more orless, resulting in only a small limited overhead.

The present invention may in particular be used to great advantage forservices defined in the context of “Wireless Village Server”, such asthose relating to Instant Messaging, Presence Information and SharedContent. However, the invention is not limited to particular serviceapplications but may be used for executing any type of service uponrequest.

While the invention has been described with reference to specificexemplary embodiments, the description is only intended to illustratethe inventive concept and should not be taken as limiting the scope ofthe invention. Various alternatives, modifications and equivalents maybe used without departing from the spirit of the invention, which isdefined by the appended claims.

1. A method of handling incoming service requests in a server systemcomprising a plurality of servers, and for distributing load between theservers, comprising: A)—receiving a service request for a client orsession, B)—assigning a primary server out of a set of primary serversto perform a processing task for the received service request, wherein aprimary server is selected for the processing task by using a firstscheduling algorithm which is adapted to select any one of the primaryservers in the set of primary servers, and C)—assigning a secondaryserver out of a set of secondary servers to perform a storing task forthe received service request, wherein the assigned primary serverselects a secondary server for the storing task by using a secondscheduling algorithm which is adapted to select a specific secondaryserver in the set of secondary servers depending on a predeterminedidentity code “user ID” of the client or session.
 2. A method accordingto claim 1, wherein the first scheduling algorithm is a Round Robinalgorithm.
 3. A method according to claim 1, wherein the secondscheduling algorithm is a hashing algorithm.
 4. A method according toclaim 3, wherein using the second scheduling algorithm in step C)includes deriving a hash number from the user ID and calculating aserver ID number from the derived a hash number.
 5. A method accordingto claim 4, further comprising using the following algorithm:server ID=hash(user ID)modulo n  (1) where n is the number of possiblesecondary servers, and the modulo operator providing an integer between0 and n−i.
 6. A method according to claim 1, wherein primary servers areassigned on an IP level, wherein the primary servers are designated andconfigured for handling requests in different protocols.
 7. A methodaccording to claim 1, wherein secondary servers are assigned on anapplication level, wherein the secondary servers are designated andconfigured for handling storing tasks in different service applications.8. A method according to claim 1, wherein the processing task involvesany of: analysing the received service request, processing of data andrunning certain applications for delivering the requested service.
 9. Amethod according to claim 1, wherein the storing task involves any of:storing new data, updating already stored data, and retrieving storeddata.
 10. A method according to claim 1, further comprising:D)—assigning a primary server out of the set of primary servers toperform a further processing task for the received service request,wherein a primary server is selected by using a third schedulingalgorithm which is adapted to select any one of the primary servers inthe set of primary servers.
 11. A method according to claim 10, whereinthe third scheduling algorithm is the same as the first schedulingalgorithm.
 12. A server system comprising a plurality of servers forhandling incoming service requests, comprising: an access node forreceiving a service request for a client or session, a set of primaryservers capable of performing at least one common processing task, and aset of secondary servers capable of performing at least one commonstoring task, wherein the access node is connected to each primaryserver and each primary server is connected to each secondary server,wherein the access node is configured to use a first schedulingalgorithm to assign any primary server in the set of primary servers forperforming a processing task for the received service request, andwherein each primary server is configured to use a second schedulingalgorithm to assign a specific secondary server in the set of secondaryservers depending on a predetermined identity code “user ID” of theclient or session, for performing a storing task for the receivedservice request.
 13. A server system according to claim 12, wherein thesecondary servers are designated for storing tasks in different serviceapplications, and comprises at least one of: Session servers, InstantMessaging servers and Presence servers.
 14. A server system according toclaim 12, wherein the primary servers are divided into different groupsfor requests in different protocols.
 15. A server system according toclaim 14, wherein a first primary server group is configured to handleMTTP requests, and a second primary server group is configured to handleHTTPS requests, wherein the first scheduling algorithm is used withinone of the primary server groups, depending on the service requestprotocol.
 16. server system according to claim 12, wherein the accessnode is configured to use a Round Robin algorithm as the firstscheduling algorithm.
 17. A server system according to claim 12, whereineach primary server is configured to use a hashing algorithm as thesecond scheduling algorithm.
 18. A server system according to claim 17,wherein each primary server is configured to use the following hashingalgorithm:server ID=hash(user ID)modulo n  (1) where n is the number of possiblesecondary servers, and the modulo operator providing an integer between0 and n−1.
 19. A server system according to claim 12, wherein eachsecondary server is configured to use a third scheduling algorithm toassign any primary server in the set of primary, servers for performinga further processing task.
 20. A server system according to claim 19,wherein the third scheduling algorithm is the same as the firstscheduling algorithm.
 21. A server system according to claim 12, whereinthe access node comprises a primary access node being configured as anormally working node handling incoming requests, and a secondary accessnode being configured to monitor the activities of the primary node, andto take over the handling of requests if the primary node for somereason fails and is shut down.